Processing device having a graphical user interface for industrial vehicle

ABSTRACT

A processing device having a graphical user interface includes a touch screen display that receives touch gesture commands from a vehicle operator and a controller. In operation, computer code implements a set of widgets such that at least one widget is normally viewable on the touch screen display. The set of widgets are organized to include at least one home screen, such as a motion home screen that displays at least one travel related widget, a lift home screen that displays at least one lift related widget, etc. When a current operating state of a control module of the industrial vehicle indicates that a designated control is engaged, the controller causes the display to snap to the associated home screen position.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/562,881, filed Sep. 6, 2019, entitled PROCESSING DEVICE HAVING AGRAPHICAL USER INTERFACE FOR INDUSTRIAL VEHICLE, now allowed, which is acontinuation of U.S. patent application Ser. No. 15/210,049, filed Jul.14, 2016, entitled PROCESSING DEVICE HAVING A GRAPHICAL USER INTERFACEFOR INDUSTRIAL VEHICLE, issued as U.S. Pat. No. 10,430,073, which claimsthe benefit of U.S. Provisional Patent Application Ser. No. 62/193,840,filed Jul. 17, 2015, entitled PROCESSING DEVICE HAVING A GRAPHICAL USERINTERFACE FOR INDUSTRIAL VEHICLE, the disclosures of which are herebyincorporated herein by reference.

BACKGROUND

The present disclosure relates to electronic systems for industrialvehicles that collect and present information to a user via a graphicaluser interface.

Wireless strategies are being deployed by business operations, includingdistributors, retail stores, manufacturers, etc., to improve theefficiency and accuracy of business operations. Wireless strategies mayalso be deployed by such business operations to avoid the insidiouseffects of constantly increasing labor and logistics costs.

In a typical wireless implementation, workers are linked to a managementsystem executing on a corresponding computer enterprise via mobilewireless transceivers. The wireless transceivers are used as interfacesto the management system to direct workers in their tasks, e.g., byinstructing workers where and/or how to pick, pack, put away, move,stage, process or otherwise manipulate the items within a facility. Thewireless transceiver may also be used in conjunction with a suitableinput device to scan, sense or otherwise read tags, labels or otheridentifiers to track the movement of designated items within thefacility.

BRIEF SUMMARY

According to aspects of the present disclosure, a processing devicehaving a graphical user interface is disclosed. The processing devicecomprises a touch screen display and a controller that is communicablycoupled to the touch screen display. The controller is operativelyprogrammed to detect gesture commands entered by an operator throughinteraction with the touch screen display. Moreover, computer codeimplements a set of widgets viewable on the touch screen display, wherethe set of widgets are organized to define a motion home screen positionthat displays at least one travel related widget, and a lift home screenposition that displays at least one lift related widget. Accordingly,when installed on an industrial vehicle, and when a current operatingstate of a traction control module of the industrial vehicle indicatesthat a traction control is engaged, the controller causes the display tosnap to the motion home screen position. Likewise, when a currentoperating state of a hydraulic module of the industrial vehicleindicates that forks are engaged in a lift operation on the industrialvehicle, the controller causes the display to snap to the lift homescreen position.

According to further aspects of the present disclosure, a processingdevice having a graphical user interface is provided. The processingdevice comprises a touch screen display and a controller that iscommunicably coupled to the touch screen display. Under thisconfiguration, the controller is operatively programmed to detectgesture commands entered by an operator through interaction with thetouch screen display. Accordingly, when installed on an industrialvehicle, computer code implements a set of widgets, where each widgetrepresents live data representing a current state associated with theindustrial vehicle or the operator. The set of widgets is organized toinclude a motion home screen position that displays at least onerelevant travel related widget. As such, when the industrial vehicle isstopped, the operator can navigate through graphical representations ofthe set of widgets on the display using the gesture commands. Also, whena current operating state of a traction control module indicates that atraction control is engaged, the controller causes the display to snapto the motion home screen position.

According to yet further aspects of the present disclosure, a processingdevice having a graphical user interface is provided. The processingdevice comprises a touch screen display and a controller that iscommunicably coupled to the touch screen display. In this regard, thecontroller is operatively programmed to detect gesture commands enteredby an operator through interaction with the touch screen display. Wheninstalled on an industrial vehicle, the processing device executescomputer code that implements a set of widgets, where each widgetrepresents live data representing a current state associated with thevehicle or the operator. The set of widgets is organized to include alift home screen position that displays at least one relevant liftrelated widget. Accordingly, when the industrial vehicle is stopped, theoperator can navigate through graphical representations of the set ofwidgets on the display using the gesture commands. Also, when a currentoperating state of a hydraulic module indicates that forks are engagedin a lift operation on the industrial vehicle, the controller causes thedisplay to snap to the lift home screen position.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a block diagram of an industrial vehicle computing enterprise,according to aspects of the present disclosure;

FIG. 2 is a block diagram of a special purpose processing device on anindustrial vehicle, according to aspects of the present disclosureherein;

FIG. 3A is an illustration of the processing device of FIG. 2,implemented as a graphical user interface having a touch screen displayand a corresponding vehicle operator control section, according toaspects of the present disclosure;

FIG. 3B is a schematic representation of the display of FIG. 3A mountedto an industrial vehicle such as a forklift truck;

FIG. 4 is a block diagram of operational components executed by aprocessor of the special purpose processing device of FIG. 2;

FIG. 5 is a schematic diagram illustrating an array of widgets fordisplay on the touch screen display of FIG. 3, according to aspects ofthe present disclosure;

FIG. 6 is a schematic screen shot of a screen display for presentationon the touch screen display of FIG. 3, according to aspects of thepresent disclosure;

FIG. 7 is a schematic screen shot of a screen display with first messagetype for presentation on the touch screen display of FIG. 3, accordingto aspects of the present disclosure;

FIG. 8 is a schematic screen shot of a screen display with secondmessage type for presentation on the touch screen display of FIG. 3,according to aspects of the present disclosure;

FIG. 9 is a schematic screen shot of a screen display with third messagetype for presentation on the touch screen display of FIG. 3, accordingto aspects of the present disclosure;

FIG. 10 is a schematic screen shot of a screen display with fourthmessage type for presentation on the touch screen display of FIG. 3,according to aspects of the present disclosure;

FIG. 11 is a schematic illustration of the processing device of FIG. 3displaying widgets according to aspects of the present disclosureherein; and

FIG. 12 is a block diagram of a computer processing system capable ofimplementing any of the systems, components, or processes described morefully herein.

DETAILED DESCRIPTION

According to various aspects of the present disclosure, a processingdevice having a graphical user interface is provided, which is suitablefor use on an industrial vehicle. The processing device includes ahousing having a front face, where the front face defines a displaysection and a vehicle operator control section. A touch screen displayis provided within the display section of the front face of the housing.The touch screen display receives touch gesture commands from a vehicleoperator.

Still further, a set of controls (e.g., designated as up, down, left,right, and select) is arranged within the vehicle operator controlsection of the front face of the housing. The set of controls includehardware control equivalents to the gesture commands recognized by thetouch screen of the display. A controller is communicably connected tothe touch screen display and the set of controls. The controller detectsinteractions with the touch screen display and the set of controls suchthat an up swipe gesture command on the touch screen and operation ofthe up control within the control section both map to the same firstgraphical user interface command. The first graphical user interfacecommand may comprise, for instance, a command to navigate up one menuoption, scroll up in an image that is too large to fit in the area ofthe display screen, etc.

The controller maps the right swipe gesture command on the touch screenand operation of the right control within the control section to thesame second graphical user interface command. The second graphical userinterface command may comprise, for instance, scrolling to the right toexpose new widgets, scrolling through a set of option choices within amenu, scrolling to the right of an image that is too large to fit in thearea of the display screen, etc.

The controller likewise maps the left swipe gesture command on the touchscreen and operation of the left control within the control section bothto the same third graphical user interface command. The third graphicaluser interface command may comprise, for instance, scrolling to the leftto expose new widgets, scrolling back out of a set of option choiceswithin a menu, scrolling to the left of an image that is too large tofit in the area of the display screen, etc.

The controller also maps the down swipe gesture command on the touchscreen and operation of the down control within the control section tothe same fourth graphical user interface command. The fourth graphicaluser interface command may comprise, for instance, a command to navigatedown one menu option, scroll down in an image that is too large to fitin the area of the display screen, etc.

The controller yet further maps the element select gesture command onthe touch screen (e.g., touch, press, release, etc.) and operation ofthe select control within the control section to the same fifthgraphical user interface command. The fifth graphical user interfacecommand may be to execute an enter command, select command,acknowledgement command, clear command, etc.

This allows industrial vehicle operators to wear gloves or otherequipment suitable for (or otherwise required by) the assigned task,without undue interference interacting with the graphical userinterface. Also, redundant control, e.g., via gesture commandsrecognized by the touch screen of the display and corresponding controlsin the vehicle operator control section, allow the vehicle operator touse whichever option is most convenient for speed, convenience,workflow, etc.

According to further aspects of the present disclosure, the graphicaluser interface enables customization of industrial vehicle operationalinformation, including customization of widgets, messaging, themes,language and other features. Moreover, in an example implementation, thevehicle operator input controls interact with, or control, elements inthe graphical user interface as viewed on the display. As such, avehicle operator can interact with the processing device, e.g., torespond to requests for information, to set up, organize, customize,etc., widgets and other display elements, or otherwise provide feedbackto the processing device using the controls of the graphical userinterface, the touch screen features of the display, or combinationsthereof.

The disclosure herein improves the technologies of industrial vehicles,operator-to-machine interaction, operation of an industrial vehicle in awork environment, and effective information push to the operator andinformation retrieval by the operator. In particular, various aspects ofthe present disclosure address the technical problem of computerinteraction in industrial environments by providing dual controlsimplemented as touch screen gesture commands and hardware equivalentcontrols that are collocated adjacent to one another in a commonhousing. The present disclosure also addresses the technical problem ofefficiently and effectively displaying (and optionally selectivelyobscuring and revealing) data including operational factors includingtime, industrial vehicle operating conditions and/or state,environmental conditions and/or state, operator conditions and/or state,combinations thereof, etc.

The processes set out herein are necessarily rooted in computertechnology to overcome problems arising with graphical user interfacesin industrial applications. In this regard, the processing devices setout herein are not merely general purpose computer components. Rather,the processing devices are special purpose machines built specificallyfor industrial vehicles used in dynamic and mobile work environmentsthat can require multiple modes of operator interaction and operation.

The technical solutions herein bring about several technical effects,including an ability to seamlessly and dynamically switch between touchgesture commands and hardware counterparts as the job and the specificapplication dictates. The technical solutions also bring about improvedindustrial vehicle performance via efficient and effective display ofrelevant information, including vehicle operating conditions and/orstate, environmental conditions and/or state, operator conditions and/orstate, combination thereof, etc.

System Overview:

Turning now to the figures and in particular to FIG. 1, a generaldiagram of a computer system 100 is illustrated according to variousaspects of the present disclosure. The illustrated computer system 100is a special purpose (particular) system that operates in a manner thatenables industrial vehicles to communicate wirelessly across a computerenterprise. The computer system 100 comprises a plurality of hardwareprocessing devices (designated generally by the reference 102) that arelinked together by one or more network(s) (designated generally by thereference 104).

The network(s) 104, e.g., wired or wireless networks, providecommunications links between the various processing devices 102 and maybe supported by networking components 106 that interconnect theprocessing devices 102, including for example, routers, hubs, firewalls,network interfaces, wired or wireless communications links andcorresponding interconnections, cellular stations and correspondingcellular conversion technologies (e.g., to convert between cellular andTCP/IP, etc.).

A processing device 102 can be any device capable of communicating overthe network 104. In certain contexts and roles, a processing device 102is intended to be mobile (e.g., a hardware-based processing device 102provided on an industrial vehicle 108 such as a forklift truck, reachtruck, stock picker, turret truck, tow tractor, rider pallet truck,walkie stacker truck, etc.). In this regard, industrial vehicles includea processing device 102 that communicates wirelessly to the network 104to carry out the features described herein. Under such circumstances,the industrial vehicles 108 can wirelessly communicate through one ormore access points 110 to a corresponding networking component 106.Also, the industrial vehicles 108 can be equipped with WiFi, cellular orother suitable technology that allows the processing device 102 on theindustrial vehicle 108 to communicate directly with a remote device(e.g., over the networks 104).

The illustrative computer system 100 also includes a hardware server 112(e.g., a web server, file server, and/or other processing device) thatsupports an analysis engine 114 and corresponding data sources(collectively identified as data sources 116). The analysis engine 114and data sources 116 provide the resources processing devices 102installed on industrial vehicles 108.

Industrial Vehicle:

Referring to FIG. 2, a processing device 202 is provided on anindustrial vehicle 108. The processing device 202 is equivalent to andan example embodiment of the processing device 102 on the industrialvehicle 108 in FIG. 1. Here, the processing device 202 is a specialpurpose, particular hardware computer, such as a device that mounts toor is otherwise integrated with the industrial vehicle 108. Theprocessing device 202 includes a processor coupled to memory to carryout instructions. However, the execution environment of the processingdevice 202 is further tied into the native electronics of the industrialvehicle 108 making it a particular machine different from a generalpurpose computer.

The illustrated processing device 202 is implemented as an informationlinking device that comprises the necessary circuitry to implementcommunication with a remote server, data and information processing forprocessing vehicle data, and wired (and optionally wireless)communication to components of the corresponding industrial vehicle 108to which the processing device 202 is mounted.

According to aspects of the present disclosure, the processing device202 is implemented as a main component 204 and a service component 206,which couple together to create an integrated device. The servicecomponent 206 is field-replaceable and includes a display (e.g., a LCD),a set of user input controls (e.g., a touch screen, buttons, switches,encoders, etc.), and any necessary data processing circuitry. In thisregard, the service component 206 provides a graphical user interface tothe processing device 202.

Graphical User Interface Component:

Referring briefly to FIG. 3A, a graphical user interface 302 isillustrated as an example implementation of the graphical user interfacecomponent 206 (FIG. 2). The graphical user interface 302 includes ahousing 304 having a front face 306 defining a display section 308 and avehicle operator control section 310. A touch screen display can beprovided within the display section 308 of the front face 306 of thehousing 304. Also, a set of controls is arranged within the vehicleoperator control section 310 of the front face 306 of the housing 304.

For instance, a display 308A within the display section 308 can includefor instance, a liquid crystal display (LCD) screen, a light emittingdiode (LED) screen, a plasma screen, etc. Moreover, the display 308A caninclude the appropriate technology to implement a touch screen so as torespond to gesture controls implemented by touching the screen, pressingagainst or releasing from the screen, swiping across the screen,performing other gesture functions associated with the display, etc.,(collectively referred to herein as gesture commands). As such thedisplay can be a touch screen display 308A.

The vehicle operator control section 310 can include buttons, switches,sliders, encoders, knobs, voice recognition, keypad, other forms ofreceiving vehicle operator input, combinations thereof, etc.

For instance, in an example implementation, the set of controls 310 iscollocated with the touch screen display 308A. For instance, the set ofcontrols 310 is aligned to the right side of the touch screen display308A as buttons arranged in a vertical proportion while still providinga navigational pattern logic to the set of controls 310.

As illustrated, the vehicle operator control section 310 includes an upcontrol (first control), i.e., up direction button 310A, a right control(second control), i.e., a right direction button 310B, a left control(third control), i.e., a left direction button 310C, a down control(fourth control), i.e., a down direction button 310D, and a selectcontrol (fifth control), i.e., a select/enter button 310E.

Alternatively, or in addition to the above, the vehicle operator controlsection 310 can include additional input devices, such as an optionalrotary encoder 310F. In an alternative embodiment, one or more of thebuttons (e.g., the buttons 310B, 310C) can be replaced by the rotaryencoder 310F or other suitable control element. For instance, a firstcontrol (e.g., right control) is implemented by rotating the encoder ina first direction (e.g., to the right) and the second control (leftcontrol) is implemented by rotating the encoder in a second direction(e.g., to the left) opposite the first direction.

The user input controls interact with, or control, elements in thegraphical user interface as viewed on the display. As such, an operatorof the industrial vehicle can interact with the processing device 202,e.g., to respond to requests for information, to set up, organize,customize, etc., widgets and other display elements, or otherwiseprovide feedback to the processing device 202.

Referring to FIG. 3B, the graphical user interface 302 of acorresponding processing device 202 is illustrated, mounted to a supportbar 352 of an industrial vehicle 108 implemented as a sit down forkliftfor convenience of illustration. In practice, the graphical userinterface 302 can be mounted in, on, to, integrated with, or otherwiseprovided for various types of industrial vehicles, including but notlimited to a forklift truck, reach truck, stock picker, turret truck,tow tractor, rider pallet truck, walkie stacker truck, etc.). Here, thehousing of the graphical user interface 302 can be mounted to the insideor outside of the corresponding industrial vehicle.

In this regard, the size, shape, and other physical characteristics canvary depending upon the application. For instance, if the housing of thegraphical user interface 302 is mounted inside an industrial vehicle,the front face can conform to neighboring structures, e.g.,instrument/control cluster, etc. If mounted to the industrial vehicle,e.g., to the support bar 352, mounts, a harness, and other supportingstructures may be provided. As such, the processing device herein isadaptable to multiple mounting options for different industrial vehicletypes and modes (with or without operator, i.e., operator controlled,semi-automated, fully automated, etc.)

In certain implementations, regardless of the form factor of thehousing, the processing device maintains a constant relationship betweenthe display 308A and vehicle operator control section 310 independent ofthe front face shape or housing size.

Main Component:

Referring back to FIG. 2, in an illustrative example, the processingdevice 202 is connected to a transceiver 212 for wireless communication.Although a single transceiver 212 is illustrated for convenience, inpractice, one or more wireless communication technologies may beprovided (e.g., WiFi, Bluetooth, and cellular). For instance, thetransceiver 212 may be able to communicate with a remote server, e.g.,server 112 of FIG. 1 via 802.11 across the access points 110 of FIG. 1.The transceiver 212 may also optionally support other wirelesscommunication, such as cellular, Bluetooth, radio frequency (RF),infrared (IR) or any other technology or combination of technologies.For instance, using a cellular to IP bridge, the transceiver 212 may beable to use a cellular signal to communicate directly with a remoteserver, e.g., a manufacturer server. The transceiver 212 connects to theprocessing device 202 via a suitable electrical connection 214, e.g., anEthernet connection. However, the transceiver 212 can connect to theprocessing device 202 using other connections. Alternatively, thetransceiver 212 can be built in or otherwise integral with theprocessing device 202.

The processing device 202 also comprises data processing circuitry thatimplements a controller, e.g., illustrated as a controller 216. Thecontroller 216 includes a processor coupled to memory for implementingcomputer instructions, including the relevant processes, or aspectsthereof, as set out and described more fully herein. The controller 216can also include other necessary processing circuitry and software, suchas for implementing a display engine, camera processing engine, dataprocessing engine(s), etc. In this regard, the controller 216 caninclude additional support circuitry, e.g., video ports, camera ports,input/output ports, etc. Moreover, the memory can include memory thatstores processing instructions, as well as memory for data storage,e.g., to implement one or more databases, data stores, registers,arrays, etc. Additionally, the controller 216 implements processes suchas operator log on, pre-use inspection checklists, data monitoring andother features, examples of which are described more fully in U.S. Pat.No. 8,060,400 to Wellman, the entirety of which is hereby incorporatedby reference herein.

The processing device 202 can also optionally include vehicle powerenabling circuitry 218 that is controlled by the controller 216 toselectively enable or disable the industrial vehicle 108 and/orselectively enable or disable select components of the industrialvehicle 108. In certain implementations, the controller 216 controls thevehicle power enabling circuitry 218 to partially enable the industrialvehicle for operation, or fully enable the industrial vehicle foroperation, e.g., depending upon proper operator login. For instance, theindustrial vehicle power enabling circuitry 218 can provide selectivepower to components via a suitable power connection, or otherwisecommand certain vehicle components not to respond to vehicle operatorcontrol via vehicle messaging, e.g., across one or more vehiclecommunication busses.

In certain implementations, the processing device 202 includes amonitoring input/output (I/O) component 220 to communicate via wired orwireless connection between peripheral devices mounted to or otherwiseon the industrial vehicle, such as cameras, sensors, meters, encoders,switches, etc. (collectively represented by reference numeral 222) andthe controller 216. The monitoring input/output (I/O) component 220 mayalso be connected to other devices, e.g., third party devices 224 suchas RFID scanners, displays, meters, bar code scanners, cameras, or otherdevices to convey information to the controller 216.

The processing device 202 is coupled to and/or communicates with otherindustrial vehicle system components via a suitable industrial vehiclenetwork system 226, e.g., at least one vehicle network bus. Theindustrial vehicle network system 226 is any wired or wireless network,bus or other communications capability (or combination of multiple,independent networks, busses or other communications capabilities) thatallows electronic components of the industrial vehicle 108 tocommunicate with each other. As an example, the industrial vehiclenetwork system 226 may comprise a controller area network (CAN) bus,ZigBee, Bluetooth, Local Interconnect Network (LIN), time-triggereddata-bus protocol (TTP), RS422 bus, Ethernet, universal serial bus(USB), other suitable communication strategy, or combinations thereof.

For instance, the controller 216 can communicate with native vehicleelectronic components such as controllers (hydraulic, traction, etc.),modules such as a battery monitor, devices such as impact sensors, etc.(collectively 228).

The controller 216 of the processing device 202 can also communicatewith a fob 230 (or keypad, card reader or any other device) forreceiving operator log in identification.

According to yet further aspects of the present disclosure, theprocessing device 202 can communicate with an environmental basedlocation tracking device 232 that is provided on the industrial vehicle108. The environmental based location tracking device 232 enables theindustrial vehicle 108 to be spatially aware of its location within alocal space, e.g., within a warehouse.

As will be described more fully herein, utilization of the industrialvehicle network system 226 enables seamless integration of thecomponents of the industrial vehicle 108 with the processing device 202,and in particular, the controller 216. By way of example, the industrialvehicle network system 226 enables communication between the controller216 and the native electronics including a vehicle control module,controllers (e.g., traction controller, hydraulics controller, etc.),vehicle specific modules and other electronic devices 228 of theindustrial vehicle 108, a fob reader 230, environmental based locationtracking 232, etc. Also, the controller 216 can facilitate thecommunication of information from any electronic peripheral devices 222or third party devices 224 associated with the industrial vehicle 108(e.g., via the monitoring I/O 220 bridging data to other vehicleresources) that integrate with and can communicate over the networksystem 226.

Thus for example, the processing device 202 connects with, understandsand is capable of communication with native vehicle components, such ascontrollers, modules, devices, bus enabled sensors, displays, lights,light bars, sound generating devices, headsets, microphones, hapticdevices, etc. (collectively referred to by reference numeral 228).

GUI Controller:

Referring generally to FIGS. 2, 3A and 3B, the controller 216 includes ahardware processor coupled to physical memory and is capable of carryingout computer-executed processes in a hardware system. In this regard,the processes, architectures and organizations described herein may beimplemented on computer-readable hardware that stores machine-executableprogram code, where the program code instructs the processor toimplement the described features.

The processor of the controller 216 executes the program code stored inthe memory to implement a graphical user interface control architecturethat passes information to, and receives information from the graphicaluser interface 302.

In particular, the controller 216 provides several distinct controlfunctions, which all interact with, and impact the manner in which thegraphical user interface module 206 (FIG. 2) presents and receivesinformation via the display 308A when interacting with a vehicleoperator. The features set out in simplified block diagram form, areexecuted by the controller 216 (FIG. 2).

Referring to FIG. 4, a control architecture 400 for a graphical userinterface is illustrated. The control architecture 400 is executed in anillustrative example, by the controller 216 of FIG. 2 (microprocessorcoupled to memory), and includes a graphical user interface (GUI)controller component 402 that controls a plurality of sub-algorithms(components) that affect the manner in which the processing device 202interacts with the vehicle operator. In this regard, the GUI controllercomponent 402 communicates with each sub-algorithm/component and furthercommunicates with the graphical user interface module 206 (FIG. 2) topresent information to the vehicle operator via the display 308A (FIG.3A), and to receive information from the vehicle operator, e.g., viatouch/gesture controls received through touching the display 308A (FIG.3A) and/or interacting with a control within the vehicle operatorcontrol section 310 (FIG. 3A) of the graphical user interface 302 (FIG.3A). In this regard, the GUI controller component 402, is alsocommunicably connected to the touch screen display 308A and the set ofcontrols 310 in the control section as described with reference to FIG.3A.

In an example implementation, the GUI controller component 402 isoperatively programmed to receive and process gesture commands from avehicle operator touching or otherwise interacting with the display 308A(FIG. 3), such as via touch, press, release, swipe, scroll, gestureproximate to, etc. Received gesture commands can include a first touchgesture command implemented as an up swipe gesture command, a secondtouch gesture command implemented as a right swipe gesture command, athird touch gesture command implemented as a left swipe gesture command,a fourth touch gesture command implemented as a down swipe gesturecommand, and a fifth touch gesture command implemented as a selectgesture command.

Likewise, the GUI controller component 402 is operatively programmed toreceive and process vehicle operator inputs from the vehicle operatorcontrol section 310 (FIG. 3) of the graphical user interface. The set ofcontrols include hardware control equivalents to the gesture commandsrecognized by the touch screen of the display.

For instance, the GUI controller component 402 maps and/or processesoperation of a first control designated as an up control (e.g., via avehicle operator pressing the up direction button 310A of FIG. 3), andthe up swipe gesture command on the touch screen display, to trigger toa first graphical user interface command. That is, an up swipe gesturecommand implemented on the touch screen display and operation of a firstcontrol in the set of controls designated as an up control both map to afirst graphical user interface command.

The GUI controller component 402 maps and/or processes operation of asecond control designated as a right control (e.g., via a vehicleoperator pressing the right direction button 310B of FIG. 3), and theright swipe gesture command, to trigger to a second graphical userinterface command. That is, a right swipe gesture command implemented onthe touch screen display and operation of a second control in the set ofcontrols designated as a right control both map to a second graphicaluser interface command.

The GUI controller component 402 maps and/or processes a third controldesignated as a left control (e.g., via a vehicle operator pressing theleft direction button 310C of FIG. 3), and the left swipe gesturecommand, to trigger to a third graphical user interface command. Thatis, a left swipe gesture command implemented on the touch screen displayand operation of a third control in the set of controls designated as aleft control both map to a third graphical user interface command.

The GUI controller component 402 maps and/or processes a fourth controldesignated as a down control (e.g., via a vehicle operator pressing thedown direction button 310D of FIG. 3) and the down swipe gesturecommand, to trigger to a fourth graphical user interface command. Thatis, a down swipe gesture command implemented on the touch screen displayand operation of a fourth control in the set of controls designated as adown control both map to a fourth graphical user interface command.

The controller component 402 maps and/or processes a fifth controldesignated as a select control (e.g., via a vehicle operator pressingthe select/enter button 310E of FIG. 3) and the select gesture commandto trigger to a fifth graphical user interface command. That is, aselect gesture command implemented on the touch screen display andoperation of a fifth control in the set of controls designated as aselect control both map to a fifth graphical user interface command.

As noted in greater detail herein, the various controls (first throughfifth) can be implemented on a single input device, e.g., a keypad, orvia separate controls, e.g., discrete buttons, one or more encoders,etc.

The first graphical user interface command may comprise, for instance, acommand to navigate a display of information provided in the display308A of the graphical user interface vertically, e.g., navigate up onemenu option or information screen, scroll up in an image that is toolarge to fit in the area of the display screen, to increment a valuethat the vehicle operator must provide as an input while interactingwith the display screen, etc.

The second graphical user interface command may comprise, for instance,a command to navigate a display of information provided in the display308A of the graphical user interface horizontally/laterally, e.g., toscroll across widgets (e.g., to expose new widgets or reveal hiddenwidgets), to drill across menus or menu option choices, navigate rightone menu option, scroll to the right in an image that is too large tofit in the area of the display screen, to index or otherwise modify adata entry value that the vehicle operator must provide as an inputwhile interacting with the display screen, etc.

The third graphical user interface command may comprise, for instance, acommand to navigate a display of information provided in the display308A of the graphical user interface horizontally/laterally, e.g., toscroll across widgets (e.g., to expose new widgets or reveal hiddenwidgets), to drill across menus or menu option choices, navigate leftone menu option, scroll to the left in an image that is too large to fitin the area of the display screen, to index or otherwise modify a dataentry value that the vehicle operator must provide as an input whileinteracting with the display screen, etc.

The fourth graphical user interface command may comprise, for instance,a command to navigate a display of information provided in the display308A of the graphical user interface vertically, e.g., navigate down onemenu option or information screen, scroll down in an image that is toolarge to fit in the area of the display screen, to decrement a valuethat the vehicle operator must provide as an input while interactingwith the display screen, etc.

The fifth graphical user interface command enables the operator toselect a menu option, enter a response, accept a value, trigger anaction, clear a message, set or stop a timer, execute an enter command,execute a select command, enter an acknowledgement command, or otherwiseinteract with the information displayed in the graphical user interfaceor in an in-focus portion thereof.

The first, second, third, fourth, and fifth graphical user interfacecommands will thus vary in function depending upon what is currentlybeing displayed on the display 308A, examples of which are described ingreater detail herein.

However, the redundancy of the gesture controls generated by touching orotherwise interacting with the display 308A and using the correspondingcontrols (e.g., buttons 310A-310E) in the vehicle operator controlsection 310 facilitates operation of the processing device 202, even inharsh environments. For instance, some forklift operators wear gloves,such as where operating in refrigerated areas of a warehouse. Moreover,the positioning of the buttons in close proximity (on the same housing)as the display 308A facilitates operator interaction by keeping theoperator consistently focused in a common area regardless of interactionwith the screen or tactile controls (e.g., buttons) when interactingwith the graphical user interface 302. Thus, in this configuration, thebuttons are co-located with the touch screen of the display.

The GUI controller component 402 also facilitates customization of theuser interaction experience. For instance, the GUI controller component402 interacts with a user management component 404. The user managementcomponent 404 is responsible for storing personalized settings that arepassed from the controller 216, such as information where read inresponse to an operator logging into a corresponding industrial vehiclevia the FOB reader 230 of FIG. 2, or via logging onto the vehicle usingthe graphical user interface 302. In an illustrative example, the usermanagement component 404 is used to store a vehicle operator performancetuning level, a theme preference, a language preference, unitmeasurement preference (e.g., metric or English), widget arrangement,etc. A generic template can be provided where there is no customizationdata available for a specific vehicle operator.

The themes may be set or limited based upon a vehicle operator level,truck level, company level, etc. Moreover, the user-selected theme canbe temporarily overridden for certain vehicle specific functionality,e.g., to provide an inspection checklist, to provide certain diagnosticinformation, etc. For instance, a system supervisor may decide to notallow theme customization, and can thus lock out that feature fromappearing as a user settable parameter.

The GUI controller component 402 also communicates with a systemmanagement component 406. The system management component 406 can beutilized to control the allowable operator-specific settings, e.g., bylimiting, disabling, enabling, etc., features. For instance, in anexample implementation, the system management component 406 controls theability of the vehicle operator to configure themes, languagepreference, widget arrangement, widget customization, etc.

The GUI controller component 402 still further communicates with a truckmanagement component 408. The truck management component 408 controlsinformation about the specific industrial vehicle 108 to which theprocessing device 202 is installed. For instance, the truck managementcomponent 408 can include information about the maximum fork height,maximum weight, battery charge, or other vehicle specificcharacteristics.

The GUI controller component 402 still further communicates with alanguage format component 410, which can be used to set a preferredlanguage for the display of text on the display 308A. In particular, thelanguage format component 410 manages the strings that need to betranslated to be pushed to the display 308A, font, text alignment,direction, and other features that affect readability of the desiredinformation by the vehicle operator.

The GUI controller component 402 still further interacts with acommunication component 412, which controls the communication of the GUIcontroller component 402 with other vehicle controllers, modules,devices, sensors, third party devices, etc., as set out in regard toFIG. 2.

The GUI controller component 402 further interacts with a message systemcomponent 414. The message system component 414 not only controls themessaging that is presented to the vehicle operator, but also the mannerin which the messaging is presented to the vehicle operator, as will bedescribed in greater detail herein.

The GUI controller component 402 also communicates with a dashboardcomponent 416. The dashboard component 416 controls widgets, the widgetorder, and the menu systems that are presented on the display 308A (FIG.3). Moreover, the dashboard component 416 is responsible for screenmanagement, e.g., by storing the current screen, next screen, previousscreen, etc. The dashboard component 416 also tracks the menus,calibration, checklists, widget display, messaging, text and videomessaging, etc.

The GUI controller component 402 also can communicate with a user I/Ocomponent 418 to translate the vehicle operator provided inputs intoinstructions that are interpreted to facilitate a vehicle operatorinteraction experience when interacting with the graphical userinterface 206, 306. For instance, the user I/O 418 can process the touchgesture commands from a vehicle operator touching the display 308A (FIG.3), or the vehicle operator-operated section of controls within thevehicle operator control section 310 (e.g., button presses), asdescribed in greater detail above.

Widget Customization:

According to aspects of the present disclosure, the display (e.g., 308Aof FIG. 3) can be utilized to display one or more “widgets”. Each widgetcan represent operating conditions and/or state, environmentalconditions and/or state, operator conditions and/or state, combinationthereof, etc. For instance, a widget can present the current state of afeature of the industrial vehicle (e.g., battery charge), the currentstate of a vehicle function or operation (e.g., current vehicle speed),or the current state of some ancillary condition (e.g., environmentalcondition such as the current time).

For instance, in an example implementation, widgets are used torepresent the current state of the vehicle speed, fork height, loadweight, battery charge, clock, stop watch, odometer, trip meter, hourmeter, time, date, etc. In this regard, the widgets represent “live”data. The current state of data values can be obtained for instance, bythe processor of the controller 216 communicating with either a masterstate data repository on the industrial vehicle 108 (e.g., where thecurrent state of monitored functions is aggregated into a commonlocation), or by communicating (e.g., querying, polling, reading from,etc.) with specific vehicle control modules, sensors, etc., across thevehicle network system 226, via the monitoring I/O 220, or a combinationthereof. Also, the current state data can be ascertained by polling orotherwise querying a remote server, e.g., the server 112 described withreference to FIG. 1, which extracts relevant data from the industrialvehicle data repository 116 and communicates that relevant data back tothe controller 216.

A widget can also represent an operator based metric, such as a currentstate of a task or operation reflecting the level of completion of thetask, (e.g., percentage of picks per shift), the current state of anoperator-based metric (e.g., operator skill level), a level of correctvehicle operation or environmental behaviors, etc. As with the above,the current state of data values can be obtained for instance, by theprocessor of the controller 216 communicating with either a master statedata repository on the industrial vehicle 108, or by communicating withspecific vehicle control modules, sensors, etc., across the vehiclenetwork system 226, via the monitoring I/O 220, or combination thereof.Also, the current state data can be ascertained by polling or otherwisequerying a remote server, e.g., the server 112 described with referenceto FIG. 1, as noted above.

By way of example, by continually data logging operator-basedperformance/operation data, e.g., at the server 112 of FIG. 1, widgetscan provide a dashboard view of key vehicle and/or operator performancemeasures. In this regard, the overall data provided in a widget need notbe limited to data collected by a specific vehicle. The widget canreflect all of the relevant industrial vehicle data associated with theoperator logged into the industrial vehicle, regardless of whichindustrial vehicle the operator is currently operating.

As noted in greater detail above, the processing device 202 iscommunicably connected to, or is otherwise integrated with acommunications device (e.g., transceiver 212) such that the processingdevice receives from a remote server (e.g., server 112), informationthat is displayed in a widget space that includes information notextracted from the vehicle 108.

Widgets can also be utilized to present industrial vehicle operatorperformance feedback to the vehicle operator. For instance, a widget canshow incorrect vs. correct defined warehouse operational behaviors,e.g., proper use of stop and horn at the end of aisles, proper use ofspeed zones, etc. By way of illustration, a widget can count thefrequency and/or duration of correct behavior events in-betweenincorrect behavior events. In this regard, information such as skilllevel, current streak, progress meter, badges, etc., can be integratedinto a “grouped” widget, or the displayed information can be simplifiedto a single metric.

According to yet further aspects of the present disclosure herein,widgets can tie into third party databases to display other information,such as operational information, messages, information from a warehousemanagement system, feeds (such as from news, sports, weather, etc.).

Widget Organization:

Referring to FIG. 5, widgets are organized into an array 500. The array500 dictates which widgets will be presented, and in which order thewidgets will be presented. For instance, a first widget 502(1) is set tothe leftmost widget, followed by widgets 502(2), 502(3) . . . 502(n),where n is any reasonable number. The vehicle operator can add as manywidgets as are available, or as are limited via preferences set in thesystem management 404 (FIG. 4). Moreover, the vehicle operator canre-arrange the order of presentation of the widgets so that the widgetsare appropriately ordered. The first two widgets can be used to set a“Home Screen” that the device can quickly jump to, e.g., to normallydisplay the two most important measures to the vehicle operator. Yetfurther, the widgets can be configured and ordered from the screenitself, e.g., by the vehicle operator, or the widgets can be set/presetby a manager or via a remote computer, which wirelessly sends thewidgets and widget order to the vehicle, such as through the remoteserver 122 of FIG. 1.

Graphical User Interface Display Screen:

Referring to FIG. 6, an example display screen 600 is illustrated. Thedisplay screen 600 is an example of a graphical user interface displayas presented by the display 308A (FIG. 3). The display screen 600 isconceptually broken down into a menu selection section 602, a firstdocked status tray 604A, an optional second docked status tray 604B, awidget space, e.g., illustrated as a first widget space 606 and a secondwidget space 608 in this example. In practice, the display screen sizemay dictate the number of widget spaces available. As such, aspectsherein are not limited to two widgets per screen.

The menu selection section 602 can be used to access a drop down set ofmenus, e.g., to set up/configure the widgets, to set preferences, etc.

The first docked status tray 604A is used to dock a limited number(e.g., 1 to 6) of specific system status icons that are frozen on thescreen regardless of which widgets are displayed. The current status ofeach vehicle status associated with a docket icon is presented. Thus,necessary maintenance required, operator performance tuning level,battery charge, time, a mailbox, a home button etc., can be frozen sothat the vehicle operator can normally see the current state of eachdocked feature and access these features regardless of which widgets arebeing displayed.

The second, optional docked status tray 604B can be used to display anidentifier, e.g., the vehicle operator name or name of another personactively logged into the vehicle, truck name, company name, location,etc.

Each widget space presents a widget comprising a visual representationof the current state of an associated function. In the illustrativeexample, two adjacent widgets are displayed, e.g., according to theorder set by the array 500. Thus, since widget N-3 is displayed in thefirst widget space 606, then widget N-2 is displayed in the secondwidget space 608. Scrolling the widgets over to the right would shiftwidget N-3 into the second widget space 608 and would shift a new widgetN-4 into the first widget space 606. Likewise, scrolling the widgetsover to the left would shift the widget N-2 into the first widget space606 and shift widget N-1 into the left widget space 608. This processcan continue to scroll through the assigned widgets. At widget 1 and N,the scrolling can stop or wrap around. An optional widget positionindicator 610 can be utilized to determine the number and position ofthe displayed widgets.

In an example implementation, a vehicle operator can only swipe or keyto a different widget when the vehicle is at a full stop. When thetravel controls of the vehicle are engaged, the display screen “snaps”back to a designated “home” position, such as the first two widgets.Moreover, the graphical user interface may be configured to havemultiple “home” screens, such as to have a home screen for travel and ahome screen for lift operations. Each designated home screen displaysone or more widgets that are relevant to the task at hand, e.g., travel,lift, etc. For instance, when traveling, the display can automaticallychange to a motion home screen that shows relevant travel relatedwidgets, e.g., speed and battery charge. Similarly, when performing alift operation, the display can automatically change to a lift homescreen that shows relevant widgets, e.g., a capacity data monitor, e.g.,by providing lift height, weight, rack selection, informationalmessages, blending information, etc.

As a few illustrative examples, the controller 216 is communicablycoupled to vehicle system modules via the vehicle network system 226. Assuch, the controller extracts from a traction control module 228 (e.g.,directly or via a memory/current vehicle state lookup table), anindication as to whether the traction control is engaged. If the currentoperating state of the traction control module indicates that thetraction controls are engaged, the controller causes the display screento “snap” back to a designated “home” position. Otherwise, the vehicleoperator can scroll through the available widgets.

As an illustrative implementation, the controller extracts from atraction control module, an indication as to whether the tractioncontrol is engaged on the industrial vehicle, and where the currentoperating state of the traction control module indicates that thetraction controls are engaged, the controller causes the display screento snap to a designated motion home position. Also, the controllerextracts from a hydraulic module, an indication as to whether the forksare engaged in a lift operation on the industrial vehicle, and where thecurrent operating state of the forks are engaged in a lift operation,the controller causes the display screen to snap to a designated lifthome position.

In another example, the controller extracts a speed of the vehicle basedupon information read from the vehicle network bus and selectivelydisables operation of the touch gesture commands (and optionallydisables the operator controls in the control area 310) when theindustrial vehicle exceeds a predetermined speed.

In yet another example, the controller (e.g., controller 216) extracts aspeed of the vehicle based upon information read from the vehiclenetwork bus and selectively disables the display of the touch screenwhen the industrial vehicle exceeds a predetermined speed.

As noted above, the controller of the controller 216 can extractinformation by communicating across the vehicle network system 226 (ormonitoring I/O 220) directly with a vehicle component. Alternatively,the controller can read the current state from a designated memory onthe industrial vehicle. For instance, a process on the industrialvehicle (e.g., a process executed by the controller/processor in thecontroller 216) may be tasked with cyclically collecting and refreshingvehicle state information in the designated memory, e.g., every 100milliseconds or less. The designated memory thus defines a vehicle statelookup table that can be accessed to make decisions based upon thecurrent operating state of the industrial vehicle. The vehicle stateinformation can be the current state of controllers, sensors, monitors,operator controls, etc. Here, the current state can reflect event codes,component states, component status information, hour meter readings,energy measurements, hydraulic measurements or other relevant data thatis associated with a corresponding industrial vehicle. Moreover, thisinformation can be used to create a history of operational data that mayvary over time, such as vehicle speed, vehicle temperature, batterystate of charge, vehicle proprietary service codes, height, weight andother measurable parameters associated with the load carrying featuresof the industrial vehicle, operator information, etc.

Messaging:

From time to time, it may be necessary to interrupt the presentation ofinformation on the display 308A to provide instructions, warnings, andother suitable messages to the vehicle operator. In this regard, thegraphical user interface 206 (FIG. 2) can support the display ofmessages in appropriate circumstances. For instance, messages can beorganized into various levels, e.g., information, warning, alert, etc.Moreover, displayed messages can persist for a predetermined amount oftime, until a vehicle operator clears the message (by pressing thescreen or button in the control section 310), until overridden by a moreimportant message, or until cleared by the vehicle, e.g., due to excessvehicle speed or other task where the display content is deemed adistraction.

Referring to FIG. 7, in a first example, a message bar 702 can bedisplayed across the bottom of the display screen so as to onlypartially block the lower portion of each displayed widget. Notably,here, the docked icons in the docked status tray 604 are not obscured.

Referring to FIG. 8, in an alternative example, an entire widget spacecan be temporarily covered up with a message. For instance, in theexample implementation, the right-most widget window is temporarilyover-ridden with a message. Once the message is cleared, eitherautomatically (times out) or cleared by the vehicle operator, theunderlying widget becomes visible again. Again, here, the docked iconsin the docked status tray 604 are not obscured.

Referring to FIG. 9, in yet another illustrative example, all viewablewidget spaces are temporarily over-ridden with a message. Once themessage is cleared, either automatically (times out) or vehicle operatorclears the message by pressing a button, e.g., the select button toacknowledge the message, the underlying widget(s) becomes visible again.Yet again however, the docked icons in the docked status tray 604 arenot obscured.

Referring to FIG. 10, yet another example message is displayed. Here,the message temporarily covers the bottom portion of the widgetwindow(s) in a manner analogous to that set out with regard to FIG. 7.However, in addition to providing a message, the system requires thevehicle operator to provide feedback, e.g., by selecting an appropriateaction, Action 1 icon 1002, Action 2 icon 1004, Action 3 icon 1006 inthis example. More or less options can be provided. Moreover, thevehicle operator may be required to provide information, e.g., byfilling in a field using a keypad, etc.

In general, the messages can be task-based messages. For instance, amaintenance message may instruct the operator to return the industrialvehicle to a service bay. A battery message may instruct the vehicleoperator to return the industrial vehicle to a battery charging station,etc.

The messaging may also be vehicle operation specific, e.g., a warningthat the vehicle operator is traveling too fast, is traveling in or neara restricted area such as a bonded area, traveling too close to theloading dock, etc.

Example Graphical User Interface Device:

Referring briefly to FIG. 11, a graphical user interface 1102 isanalogous to the graphical user interface component 206 (FIG. 2) andgraphical user interface 302 (FIG. 3). The graphical user interface 1102includes a housing 1104 having a front face 1106 defining a displaysection 1108 and a vehicle operator control section 1110. A display1108A within the display section 1108 (e.g., touch screen) illustratesthe display of two widgets, as described with reference to FIGS. 5-10.

The vehicle operator control section 1110 is illustrated as includingfive keys/buttons. For instance, as illustrated, the vehicle operatorcontrol section 1110 includes an up direction button 1110A, a rightdirection button 1110B, a left direction button 1110C, a down directionbutton 1110D, and an enter button 1110E.

Vehicle Operation Controlled Display of Information:

According to aspects of the present disclosure, the operating state ofthe industrial vehicle can be used to selectively modify, lock out,change, or otherwise modify the information viewable on the display. Forinstance, with reference generally to FIGS. 2, 3A, and 4, and as notedin greater detail herein, the GUI controller component 402 (e.g., viathe controller 216) can communicate with vehicle components across thevehicle network system 226. As such, in an illustrative implementation,the controller extracts an event, such as a speed of the vehicle, forkheight, load weight, load contents, etc., and based upon informationread from the vehicle network system, selectively modifies, controls,augments, disables, etc., operation of the touch gesture commands and/oroperator controls in the controls section 310 when the industrialvehicle exceeds a predetermined threshold associated with the event. Anynumber of events and thresholds can be detected and used to modify theperformance of the graphical user interface in any desired combination.

As yet another example, the controller can extract speed of the vehiclebased upon information read from the vehicle network system, andselectively disables the display of the touch screen, e.g., to hide thewidgets, when the industrial vehicle exceeds a predetermined speed. Asstill another example, the system can disable tap and swipe (as well askey entered information) unless the vehicle is at a stop. As anotherexample, when the vehicle starts to travel, the dashboard can transitionback to the first two widgets, e.g., implementing a return to HomeScreen functionality.

Calibration:

With reference to the FIGURES generally, the graphical user interface206 can be used to walk a vehicle operator through a calibrationprocess, e.g., to calibrate one or more vehicle functions, e.g., to settime/date, to calibrate load sensors, set operation set points, etc.

Operator Login:

The display screen can present a vehicle operator login prompt. If thevehicle operator fails to provide a proper operator ID, the controller402 of the processing device 202 can communicate with the power enablingand conditioning circuitry 218 to temporarily disable all or part of thevehicle (e.g., limit travel speed to a limp mode/crawl), etc. Theinteraction between the control component 402 and the power enabling andcontrol circuitry 218 also enables a “push to start” feature to startthe industrial vehicle for normal operation by pressing a special buttongraphically displayed in the graphical user interface.

Messages:

The robustness of the graphical user interface, in combination with theintegration of the processor to vehicle operator login, andcommunication with a remote server facilitates the ability to send andreceive electronic messages to the vehicle operator. At appropriatetimes, e.g., when the industrial vehicle is not moving, the messagecontents can be directed to the graphical user interface. If an event isdetected, such as the industrial vehicle moving, lifting or otherwiseworking, the messages can be automatically disabled. A message icon canbe one of the docked icons in the docket status tray 604.

Rich Display Screen:

At designated times, e.g., when the industrial vehicle is not moving,the graphical user interface can also be utilized to display rich,graphic intensive information, such as operators manuals, maintenancerepair manuals, schematics for maintenance personnel, etc. Where animage, text, etc. is too large to fit into the viewing area of thedisplay screen, the user can use the controls to navigate up, down, leftand right to move parts of the image, text, etc., into the viewable areaof the display screen.

Miscellaneous:

In an example implementation, the processing device includes a vehiclenetwork bus connection, e.g., a connection to the vehicle networksystem/bus 226 of the industrial vehicle as best described withreference to FIG. 2.

In an example implementation, the controller is further operativelyprogrammed to extract a speed of the vehicle based upon information readfrom the vehicle network bus, and selectively disable operation of atleast one gesture command when the extracted speed exceeds apredetermined speed threshold. The controller can also disable operationof at least one control (e.g., on button). Moreover, all user inputs(gesture commands and controls) can be disabled, or any combinationthereof can be disabled.

In another example implementation, the controller is further operativelyprogrammed to extract a speed of the vehicle based upon information readfrom the vehicle network bus, and selectively disable the display of thetouch screen when the extracted speed exceeds a predetermined speedthreshold.

In yet another example implementation, the touch screen displaygraphically displays a widget space for displaying a widget comprising avisual representation of a current state of an associated component ofthe industrial vehicle. Here, the controller is further operativelyprogrammed to extract the current state of the associated component ofthe industrial vehicle by communicating with at least one electroniccomponent across the vehicle network bus.

Moreover, as noted in the examples above, in example configurations, thetouch screen display further graphically displays a menu selectionsection, and a docked status tray that graphically displays at least oneicon, each icon representing the current state of a vehicle component.Here, the controller is further operatively programmed to periodicallyextract the current state of each vehicle component associated with anicon in the docked status tray by submitting a query across the vehiclenetwork bus to at least one industrial vehicle electronic component. Forinstance, the widget space can display the current state of at least oneof battery charge, vehicle speed, or fork lift height.

As another example, the controller can be further operatively programmedto receive information from another component of the industrial vehicle(e.g., a transceiver in communication with a remote server, memory,query engine, etc.), and interact with the touch screen display to causethe widget space to display the current state of at least one ofenvironmental state, and a task-based state reflecting the level ofcompletion of the task. For instance, the controller can interact with acommunications device such that the controller receives from a remoteserver, information that is displayed in the widget space that includesinformation not extracted from the vehicle.

Likewise, the controller can be further operatively programmed toreceive information from another component of the industrial vehicle(e.g., the transceiver in communication with a remote server) andinteract with the touch screen display to cause the widget space todisplay the current state of at least one measure of operatorperformance. As an example, the controller can be operatively programmedto cause the touch screen display to display a count of the frequencyand/or duration of correct behavior events in-between incorrect behaviorevents.

In still a further example, the controller can be further operativelyprogrammed to receive information from another component of theindustrial vehicle, and interact with the touch screen display to causethe widget space to be temporarily interrupted to display a messageacross a lower portion of the widget space that is removed after aperiod of time.

In addition and/or alternatively, the controller can be furtheroperatively programmed to receive information from another component ofthe industrial vehicle, and interact with the touch screen display tocause the widget space to be temporarily interrupted to display amessage across the entirety of a single widget space that is removedafter a period of time. In addition and/or alternatively, the controllercan be further operatively programmed to receive information fromanother component of the industrial vehicle, and interact with the touchscreen display to temporarily display a message across the entirety ofall displayed widget spaces for a period of time.

In yet further example configurations, the controller is operativelyprogrammed to clear the displayed message after any one of the vehicleoperator presses a designated area of the touch screen, a button in thevehicle operator control area, or a combination thereof, the messagetimes out, the message is cleared to display a higher priority message,or the message is cleared to clear the display screen based upon adesignated operating characteristic of the vehicle. For instance, thecontroller can be operatively programmed to clear the message from thedisplay screen based upon a designated operating characteristic of thevehicle if the controller detects that the industrial vehicle istraveling in excess of a predetermined speed.

In example configurations the controller controls the touch displayscreen such that the widget space snaps to a first home positiondisplaying at least one designated widget when the vehicle is notstationary. In other example configurations, the controller controls thetouch display screen such that the widget space snaps to a first homeposition displaying at least one designated widget when the vehicletraction control is engaged. As an example, the controller extracts froma traction control module, an indication as to whether the tractioncontrol is engaged on the industrial vehicle, and where the currentoperating state of the traction control module indicates that thetraction controls are engaged, the controller causes the display screento snap to a designated home position.

In yet another example configuration, the controller controls the touchdisplay screen such that the widget space snaps to a second homeposition displaying at least one designated widget when the vehicle liftcontrol is engaged.

As yet another example, the controller extracts from a traction controlmodule, an indication as to whether the traction control is engaged onthe industrial vehicle, and where the current operating state of thetraction control module indicates that the traction controls areengaged, the controller causes the display screen to snap to adesignated motion home position. Also, the controller extracts from ahydraulic module, an indication as to whether the forks are engaged in alift operation on the industrial vehicle, and where the currentoperating state of the forks are engaged in a lift operation, thecontroller causes the display screen to snap to a designated lift homeposition.

Computer System Overview:

Referring to FIG. 12, a schematic block diagram illustrates an exemplarycomputer system 1200 for implementing the processing device of FIG. 2,the controller 216 of FIG. 2, the control architecture 400 of FIG. 4, orother processing structures set out more fully herein. The exemplarycomputer system 1200 includes one or more (hardware) microprocessors (g)1210 and corresponding (hardware) memory 1220 (e.g., random accessmemory and/or read only memory) that are connected to a system bus 1230.Information can be passed between the system bus 1230 and an optionaldata bus 1240 by a suitable bridge 1250. The data bus 1240 is used tointerface peripherals with the one or more microprocessors (g) 1210,such as storage 1260 (e.g., solid state hard disk drive); removablemedia storage devices 1270 (e.g., flash drives, etc.); I/O devices 1280(e.g., the graphical user interface 206, a universal serial bus (USB)interface, etc.); and one or more adapters 1290. The adapters 1290,where provided, allow the microprocessor 1210 to communicate across oneor more of the vehicle network systems (e.g., 226 of FIG. 2). In thisregard, example adapters 1290 can include Bluetooth, Ethernet, CAN bus,RS422, LIN Bus, WIFI, cellular, etc.

The above list of peripherals is presented by way of illustration, andis not intended to be limiting. Other peripheral devices may be suitablyintegrated into the computer system 1200. The memory 1220, storage 1260,removable media insertable into the removable media storage 1270 orcombinations thereof, can be used to implement the processes,configurations, interfaces and other aspects set out and describedherein.

The microprocessor(s) 1210 control operation of the exemplary computersystem 1200. Moreover, one or more of the microprocessor(s) 1210 executecomputer readable code that instructs the microprocessor(s) 1210 toimplement the processes herein. The computer readable code may be storedfor instance, in the memory 1220, storage 1260, removable media storagedevice 1270 or other suitable tangible storage medium accessible by themicroprocessor(s) 1210. The memory 1220 can also function as a workingmemory, e.g., to store data, an operating system, etc.

The processes herein may be implemented as a machine-executable processexecuted on a computer system, e.g., one or more of the processingdevices 102 of FIG. 1, on a particular computing device such as thevehicle computer processing device 202 described with reference to FIGS.2-11, on the control architecture 400 of FIG. 4, on a system 1200 ofFIG. 12, or combination thereof. In this regard, the processes hereinmay be implemented on a computer-readable storage device (e.g.,computer-readable storage hardware) that stores machine-executableprogram code, where the program code instructs a processor to implementthe described method/process. The processes herein may also be executedby a processor coupled to memory, where the processor is programmed byprogram code stored in the memory, to perform the described process.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages. The program code may execute entirely on thecomputer system 1200 or partly on the computer system 1200. In thelatter scenario, the remote computer may be connected to the computersystem 1200 through any type of network connection, e.g., using thenetwork adapter 1290 of the computer system 1200.

In implementing computer aspects of the present disclosure, anycombination of computer-readable medium may be utilized. Thecomputer-readable medium may be a computer readable signal medium, acomputer-readable storage medium, or a combination thereof. Moreover, acomputer-readable storage medium may be implemented in practice as oneor more distinct mediums.

A computer-readable signal medium is a transitory propagating signal perse. A computer-readable signal medium may include computer readableprogram code embodied therein, for example, as a propagated data signalin baseband or as part of a carrier wave. However, specifically, acomputer-readable signal medium does not encompass a computer-readablestorage medium.

A computer-readable storage medium is a tangible device/hardware thatcan retain and store a program (instructions) for use by or inconnection with an instruction execution system, apparatus, or device,e.g., a computer or other processing device set out more fully herein.Notably, a computer-readable storage medium does not encompass acomputer-readable signal medium. Thus, a computer readable storagemedium, as used herein, is not to be construed as being transitorysignals per se, such as radio waves or other freely propagatingelectromagnetic waves through a transmission media.

Specific examples (a non-exhaustive list) of the computer-readablestorage medium include the following: a hard disk, a random accessmemory (RAM), a read-only memory (ROM), an erasable programmableread-only memory (EPROM), Flash memory, or any suitable combination ofthe foregoing. In particular, a computer-readable storage mediumincludes computer-readable hardware such as a computer-readable storagedevice, e.g., memory. Here, a computer-readable storage device andcomputer-readable hardware are physical, tangible implementations thatare non-transitory.

By non-transitory, it is meant that, unlike a transitory propagatingsignal per se, which will naturally cease to exist, the contents of thecomputer-readable storage device or computer-readable hardware thatdefine the claimed subject matter persists until acted upon by anexternal action. For instance, program code loaded into random accessmemory (RAM) is deemed non-transitory in that the content will persistuntil acted upon, e.g., by removing power, by overwriting, deleting,modifying, etc.

Moreover, since hardware comprises physical element(s) or component(s)of a corresponding computer system, hardware does not encompasssoftware, per se.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The description of the present disclosure has been presented forpurposes of illustration and description, but is not intended to beexhaustive or limited to the invention in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the invention.

Having thus described the invention of the present application in detailand by reference to embodiments thereof, it will be apparent thatmodifications and variations are possible without departing from thescope of the invention defined in the appended claims.

What is claimed is:
 1. A processing device having a graphical userinterface, the processing device comprising: a touch screen display; anda controller communicably coupled to the touch screen display, whereinthe controller is operatively programmed to detect gesture commandsentered by an operator through interaction with the touch screendisplay; wherein: computer code implements a set of widgets such that atleast one widget is normally viewable on the touch screen display, theset of widgets organized to include: a motion home screen position thatdisplays at least one travel related widget; and a lift home screenposition that displays at least one lift related widget; wherein, wheninstalled on an industrial vehicle: when a current operating state of atraction control module of the industrial vehicle indicates that atraction control is engaged, the controller causes the touch screendisplay to snap to the motion home screen position; and when a currentoperating state of a hydraulic module of the industrial vehicleindicates that forks are engaged in a lift operation on the industrialvehicle, the controller causes the touch screen display to snap to thelift home screen position.
 2. The processing device of claim 1, wherein:the touch screen display is implemented on a service component that isfield replaceable; the controller is implemented on a main component;and the service component mounts to the main component.
 3. Theprocessing device of claim 1, wherein: the touch screen displaygraphically displays: a widget space for displaying a select one of theset of widgets comprising a visual representation of a current state ofan associated component of the industrial vehicle; and the controller isfurther operatively programmed to extract the current state of theassociated component of the industrial vehicle by communicating with atleast one electronic component across a vehicle network bus.
 4. Theprocessing device of claim 3, wherein the touch screen display furthergraphically displays: a menu selection section; and a docked status traythat graphically displays at least one icon, each icon representing acurrent state of a vehicle component; wherein the controller is furtheroperatively programmed to periodically extract the current state of eachvehicle component associated with an icon in the docked status tray bysubmitting a query across the vehicle network bus to at least oneindustrial vehicle electronic component.
 5. The processing device ofclaim 3, wherein the widget space displays the current state of at leastone of battery charge, vehicle speed, or fork lift height.
 6. Theprocessing device of claim 3, wherein the controller is furtheroperatively programmed to receive information from another component ofthe industrial vehicle, and interact with the touch screen display tocause the widget space to display the current state of at least one of:an environmental state; a task-based state reflecting a level ofcompletion of a task; and a count of a frequency and/or duration ofcorrect warehouse operational behavior events in-between incorrectbehavior events.
 7. The processing device of claim 3, wherein thecontroller is further operatively programmed to receive information fromanother component of the industrial vehicle, and interact with the touchscreen display to cause the widget space to be temporarily interruptedto display a message across a select one of: a lower portion of thewidget space that is removed after a period of time; a single widgetspace that is removed after a period of time; or the entirety of alldisplayed widget spaces for a period of time.
 8. The processing deviceof claim 3, wherein: the controller is further operatively programmed toreceive information from another component of the industrial vehicle,and interact with the touch screen display to cause the widget space tobe temporarily interrupted to display a message that is removed after aperiod of time; and the controller is operatively programmed to clearthe displayed message after any one of: the operator presses adesignated area of the touch screen, a button in a vehicle operatorcontrol area, or a combination thereof; the message times out; themessage is cleared to display a higher priority message; or the messageis cleared to clear the touch screen display based upon a designatedoperating characteristic of the industrial vehicle.
 9. The processingdevice of claim 1 further comprising: a control area having a set ofcontrols configured such that: a first swipe gesture command implementedon the touch screen display and operation of a first control in the setof controls designated as a right control both map to a first graphicaluser interface command; a second swipe gesture command implemented onthe touch screen display and operation of a second control in the set ofcontrols designated as a left control both map to a second graphicaluser interface command; and a select gesture command implemented on thetouch screen display and operation of a third control in the set ofcontrols designated as a select control both map to a third graphicaluser interface command.
 10. The processing device of claim 9, wherein:the first control is implemented as a first button assigned to the rightcontrol; the second control is implemented as a second button assignedto the left control; and the third control is implemented as a thirdbutton assigned to the select control.
 11. A processing system for useon an industrial vehicle, comprising: a touch screen display; and acontroller communicably coupled to the touch screen display, wherein thecontroller is operatively programmed to detect gesture commands enteredby an operator through interaction with the touch screen display;wherein when installed on the industrial vehicle: computer codeimplements a set of widgets, each widget representing live datarepresenting a current state associated with the industrial vehicle orthe operator, the set of widgets organized to define a motion homescreen position that displays at least one relevant travel relatedwidget; when the industrial vehicle is stopped, the operator cannavigate through graphical representations of the set of widgets on thetouch screen display using the gesture commands; and when a currentoperating state of a traction control module indicates that a tractioncontrol is engaged, the controller causes the touch screen display tosnap to the motion home screen position.
 12. The processing device ofclaim 11, wherein: the touch screen display graphically displays: awidget space for displaying a select one of the set of widgetscomprising a visual representation of at least one of battery charge,vehicle speed, or fork lift height; a menu selection section; and adocked status tray that graphically displays at least one icon, eachicon representing a current state of a vehicle component; wherein: thecontroller is further operatively programmed to periodically extract thecurrent state of each vehicle component associated with an icon in thedocked status tray by submitting a query across a vehicle network bus toat least one industrial vehicle electronic component.
 13. The processingdevice of claim 12, wherein the controller is further operativelyprogrammed to interact with the touch screen display to cause the widgetspace to display a current state of at least one of: an environmentalstate; a task-based state reflecting a level of completion of a task;and a count of the frequency and/or duration of correct warehouseoperational behavior events in-between incorrect behavior events. 14.The processing device of claim 12, wherein the controller is furtheroperatively programmed to receive information from another component ofthe industrial vehicle, and interact with the touch screen display tocause the widget space to be temporarily interrupted to display amessage across a select one of: a lower portion of the widget space thatis removed after a period of time; a single widget space that is removedafter a period of time; or the entirety of all displayed widget spacesfor a period of time.
 15. The processing device of claim 11, wherein:the touch screen display is implemented on a service component that isfield replaceable; the controller is mounted to a main component; theservice component mates to the main component to define a housing; thehousing further comprises a set of controls arranged within a controlsection; a right swipe gesture command implemented on the touch screendisplay and operation of a first control in the set of controls both mapto a first graphical user interface command; a left swipe gesturecommand implemented on the touch screen display and operation of asecond control in the set of controls both map to a second graphicaluser interface command; and a select gesture command implemented on thetouch screen display and operation of a third control in the set ofcontrols designated as a select control both map to a third graphicaluser interface command.
 16. A processing device having a graphical userinterface, the processing device comprising: a touch screen display; anda controller communicably coupled to the touch screen display, whereinthe controller is operatively programmed to detect gesture commandsentered by an operator through interaction with the touch screendisplay; wherein when installed on an industrial vehicle: computer codeimplements a set of widgets, each widget representing live datarepresenting a current state associated with the industrial vehicle orthe operator, the set of widgets organized to define a lift home screenposition that displays at least one relevant lift related widget; whenthe industrial vehicle is stopped, the operator can navigate throughgraphical representations of the set of widgets on the touch screendisplay using any combination of the gesture commands; and when acurrent operating state of a hydraulic module indicates that forks areengaged in a lift operation on the industrial vehicle, the controllercauses the touch screen display to snap to the lift home screenposition.
 17. The processing device of claim 16, wherein: the touchscreen display graphically displays: a widget space for displaying aselect one of the set of widgets comprising a visual representation ofat least one of battery charge, vehicle speed, or fork lift height; amenu selection section; and a docked status tray that graphicallydisplays at least one icon, each icon representing a current state of avehicle component; wherein: the controller is further operativelyprogrammed to periodically extract the current state of each vehiclecomponent associated with an icon in the docked status tray bysubmitting a query across a vehicle network bus to at least oneindustrial vehicle electronic component.
 18. The processing device ofclaim 17, wherein the controller is further operatively programmed tointeract with the touch screen display to cause the widget space todisplay a current state of at least one of: an environmental state; atask-based state reflecting a level of completion of a task; and a countof a frequency and/or duration of correct warehouse operational behaviorevents in-between incorrect behavior events.
 19. The processing deviceof claim 17, wherein the controller is further operatively programmed toreceive information from another component of the industrial vehicle,and interact with the touch screen display to cause the widget space tobe temporarily interrupted to display a message across a select one of:a lower portion of the widget space that is removed after a period oftime; a single widget space that is removed after a period of time; orthe entirety of all displayed widget spaces for a period of time. 20.The processing device of claim 16 further comprising: a set of controlsarranged within a control section, wherein: the set of controls and thetouch screen display are implemented on a service component that isfield replaceable; the controller is mounted to a main component; theservice component mates to the main component to define a housing; aright swipe gesture command implemented on the touch screen display andoperation of a first control in the set of controls both map to a firstgraphical user interface command; a left swipe gesture commandimplemented on the touch screen display and operation of a secondcontrol in the set of controls both map to a second graphical userinterface command; and a select gesture command implemented on the touchscreen display and operation of a third control in the set of controlsdesignated as a select control both map to a third graphical userinterface command.